home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 6815 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.0 KB
  1. Path: beavis.kronos.com!usenet
  2. From: porter_woodward@internet.kronos.com (Porter Woodward)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: AB3D II beats Quake....
  5. Date: 3 Apr 1996 12:30:04 GMT
  6. Organization: Software Quality Assurance
  7. Distribution: world
  8. Message-ID: <4jtr0c$3vn@beavis.kronos.com>
  9. References: <4jbkpc$mbr@mopo.cc.lut.fi> <1434.6662T1116T1344@epma.demon.co.uk> <6932.6665T243T2605@mbox.vol.it>
  10. NNTP-Posting-Host: 158.228.60.147
  11. Mime-Version: 1.0
  12. Content-Type: Text/Plain; charset=US-ASCII
  13. X-Newsreader: WinVN 0.99.7
  14.  
  15. In article <6932.6665T243T2605@mbox.vol.it>, bizzetti@mbox.vol.it says...
  16. >
  17. >
  18. >>>>C is slow as hell, and if you say "it's fast enough with a 700Mhz CPU" then
  19. >>>>I tell you that also assembly becomes faster with the 700Mhz CPU. You're
  20. >>>>running away from your shadow: ASM will always be losta faster and better
  21. >>>>than C.
  22. >
  23. >>F(l)abio, ;-)
  24. >
  25. >>I agree with you that 68000 is neccesary to get the best out of the
  26. >>amiga, not many demos etc. are written in C (thank god!).  However you are
  27. >>wrong to assume that compilers cannot generate code as well as humans.  As we
  28. >>are moving into the RISC era, CPUs have fewer instructions which are a lot
  29. >>easier for a compiler to make great code with, in fact on certain mainframe
  30. >>systems compilers generate code which is as fast as we could write in asm.
  31. >
  32. >Yes :) but why it must be asm or C? :)
  33.  
  34.     There is no need to treat them as mutually exclusive!  In fact,
  35. I've found it highly useful to do time intensive (on CPU) operations with
  36. assembly routines, and call them from C/C++.  Something like an integer
  37. based square root routine with no divide operands...  Then instead of
  38. calling the normal C sqr function, I call my own asm sqroot function, and
  39. pass the parameter in D0!  Works very quickly.
  40.  
  41. >1) asm gets too complex. In this case, I recall the old days of 6502 and it
  42.  
  43.     Ahh yes - I remember it now - Computer Science courses from high
  44. school!  Having to write your own routines to do multiplication and division, etc.
  45. It wasn't so bad really - It's just that there was _nothing_ to work with, you had
  46. to do it all.  All the stupid little statements that you take for granted in a higher
  47. level language didn't exist.
  48.  
  49.     In essence, the trend is toward very, very complex assembly language
  50. on CPUs.  With the next generation (probably VLIW) most people will find it very
  51. difficult to code in assembly.  RISC is bad enough.  However, I don't think a
  52. computer will be able to replace a human in terms of "high level" optimizations.
  53. That is being able to look at the overall problem and come up with all sorts of
  54. schemes to speed stuff up.  There will still be a place for "hand tuning".
  55.  
  56. >2) If you think that C and ASM performaces get closer new CPU after new CPU,
  57. >   I can't really agree. The reasons you explained before make people exploit
  58. >   less the assembly advantages, for the implicit idea to keep on the tradition
  59. >   with pure assembly, where they should know that assembly itself is already
  60. >   not M/L. If C was really so good (and can't be, for definition, because it's
  61. >   a portable language, thus cannot be optimized to the best possible), then why
  62.  
  63.     C by definition isn't portable.  Each machine has an implementation
  64. specific to it, and it alone.  The end result is a language that most computers
  65. have compilers for that can translate the higher level language to native
  66. CPU operands.  That is like saying BASIC is portable.  Yeah, the program code
  67. you wrote might be, but the BASIC compiler/interpreter isn't.
  68.  
  69.     One thing about the 680x0/80x86 compiler war.  It's really only
  70. recently that compilers have been optimized to take advantage of the larger
  71. register set on the 680x0 processors (say about 5 years) - prior to that compiler
  72. theory wasn't all that great - and it really was only in the early 80s that C
  73. was coming into vogue!  Prior to that, computers were pretty simple affairs (at
  74. least those available in any massiv scale).  As compiler theory advances, you
  75. will find that they will be able to take advantage of cpus with register sets (say
  76. 64 data registers) in ways that we can't really understand.
  77.  
  78.                         - Porter Woodward
  79.  
  80. -- 
  81. ****************************************************************
  82.              (Oh, so that's what's on the other side!)          
  83.             o   "Sometimes truth IS stranger than fiction."     
  84.            o  I can be reached at:                              
  85.           o   porter_woodward@internet.kronos.com -daytime      
  86.        \|/    OR     woodward@acad.wit.edu        -nights       
  87.        @ @    OR   http://www.kronos.com/~porter/ -always       
  88. ___oOO_(_)_OOo__________________________________________________
  89.    |   |   |   |   |   |   |   |   |   |   |   |   |INTEL  |   |
  90.    |+------------------------------------+ | @ |   |  OUTSIDE  |
  91.    ||  //\                               | |   |   |   |   |   |
  92.    ||\X/--\MiGA - Make up your own mind. | |   |   |JUST SAY NO|
  93. @  |+------------------------------------+ |   |  o|   | TO|   |
  94.    |   |   |   |   |   |   |   |   |   |   |*  |   | Micro$oft |
  95. ////////////////////////////////////////////////////////////////
  96.  
  97.